-
Notifications
You must be signed in to change notification settings - Fork 125
[HTTP2] Prepare migration actions #456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
http2State: HTTP2StateMachine, | ||
newHTTP1Connection: Connection | ||
) -> Action { | ||
self.migrateFromHTTP1( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very confusing: why is the outer function called migrateFromHTTP2
and the inner one called migrateFromHTTP1
?
Sources/AsyncHTTPClient/ConnectionPool/State Machine/HTTPConnectionPool+HTTP2Connections.swift
Show resolved
Hide resolved
@@ -317,7 +351,7 @@ extension HTTPConnectionPool { | |||
/// - Parameters: | |||
/// - starting: starting HTTP connections from previous state machine | |||
/// - backingOff: backing off HTTP connections from previous state machine | |||
mutating func migrateConnections( | |||
mutating func migrateFromHTTP2( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its this name right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, good catch. It should be migrateFromHTTP1
let request: HTTPConnectionPool.StateMachine.RequestAction | ||
let connection: EstablishedConnectionAction | ||
|
||
var asStateMachineAction: HTTPConnectionPool.StateMachine.Action { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would normally be spelled as an initializer on the target type, which already exists. Do we need the helper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a bit more convenient but I will remove it.
case .closeConnection(let connection, let isShutdown): | ||
return .migration( | ||
createConnections: migrationAction.createConnections, | ||
closeConnections: migrationAction.closeConnections + CollectionOfOne(connection), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if including CollectionOfOne
is the most efficient way to achieve this append.
case migration( | ||
createConnections: [(Connection.ID, EventLoop)], | ||
closeConnections: [Connection], | ||
isShutdown: StateMachine.ConnectionAction.IsShutdown |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In which case would we run into this? I guess if we are in http/1 and are closing and a new http/2 connection comes up we should just close the new connection. No migrations should occur if we are in shutdown.
5908084
to
d9a1bb6
Compare
89e35d0
to
17a1d0c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor style nit, otherwise this looks good.
if self.http2Connections!.isEmpty { | ||
self.http2Connections = nil | ||
} | ||
if self.connections.isEmpty, self.http2Connections == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer &&
to ,
when we aren't doing conditional binding.
Motivation
During migration from HTTP/1.x to HTTP/2 (and vice versa) we may need to close and/or create connections. We previously did not allow any actions during migration. This PR lifts that limitation.
Changes
.migration
case toAction
to allow all possible combinations of actions that can happen during migrationConnectionMigrationAction
andEstablishedConnectionAction
which can me combined to a "normal"ConnectionAction
with the static.combined(_:_)
method onConnectionAction
EstablishedAction
in the private implementation to be able to combine it with aConnectionMigrationAction